I'll review COBS a bit closer, but generally I don't see a huge problem using something like this for this. We don't really need advanced features like protobuf for things like this, e.g. backwards/forwards compat with encoded data, etc.

The general approach: I agree, there's definitely some duplication. I'd love our final solution to abstract out just the "transport" portion into an API that allows swapping out the implementation of just that piece, instead of duplicating the whole thing, but I understand the hesitancy to do this "too early". I think as long as we have an eye on this eventual de-dup, I'm fine with it.

Now that upstream Zephyr in recent versions has added a PIO based UART driver, I think sticking with "UART device as the abstraction level" is reasonable and will offer enough flexibility I don't think we need our own "wired transport" abstraction over the UART driver one.

Thanks for picking this up!

I've got great interest in this, and will be tracking and testing, and porting to Lulu and another unnamed board as soon as PIO is working. I have a backlog of 2 wire splits that I'd love to see get full ZMK support. Not sure how much I can contribute on a code front, but more than willing to give feedback and stress test.

@kdb424 do you need PIO on both sides? For now I only implemented PIO on the peripheral side because:

• My hw is wired in a way that the receiver supports hardware UART(rx only)
• The PIO driver is (currently) polling only which means that it can impact the whole system because it prevents any other threads from running. That's okay for the peripheral side because there we're just sending and can thus control when we want to send data. Also, the peripheral doesn't have anything else to do anyway because BLE/USB/... are all handled by the central.

I've got one and two wire RP2040 boards of various pins used. I'm sure I have something around that I can test with, from dev boards, to full keyboards. I'll find something that works with it to test.

I'm not super familiar with the way QMK/ZMK and these communications work, so this is a pretty layman's question, but to what extent are the remaining TODO items core functionality (which to me means "I can put a nice nano v2 on one half and a sea picro on the other half and the keypresses all register") vs nice-to-haves? More specifically, is this ready for beta testing with that core functionality?

Also very curious to know what the status of this is. I've got a wired split keyboard with two sea picros, in theory would I be able to use this branch and things would work?

I still intend to clean this up and make this mergeable. I simply got distracted because I'm currently in my keyboard exploration phase to find the best one 😅

Assuming you configure your devicetree correctly, this should work for you as is. I've tested this on two (custom) keyboards so far.

I still intend to clean this up and make this mergeable.

Do you have some sort of estimate when you will probably get to it?
I'd also gladly help, if I can do something (do not have much experience with open-source yet but would love to get into it).

Not sure how this and #2080 interact, but worth noting.

Not sure how this and #2080 interact, but worth noting.

Thanks for mentioning this. It sounds like this needs to be coordinated better (by the ZMK maintainers?) so we'll work together instead of re-implementing the same thing over and over again and dumping WIP PRs in here.

That being said, from reading the description(I didn't read the code, yet) it looks like it supports more usecases.

Excited about wired split support! For the layman who doesn't fully understand UART, what types of cables could be used to connect peripheral to central? TRRS? USB-C? RJ45?

@M1cha I'd like to give this PR a go. Obviously as it's in it's early stages it's lacking some docs. Is your corne-keyboard repo the best example of this in action?